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Donate to the Foundation! 

You already know that FreeBSD is an internationally 
recognized leader in providing a high-performance, 
secure, and stable operating system. It's because of 
you. Your donations have a direct impact on the Project. 

Please consider making a gift to support FreeBSD for the 
coming year. It's only with your help that we can continue 
and increase our support to make FreeBSD the high- 
performance, secure, and reliable OS you know and love! 

Your investment will help: 

• Funding Projects to Advance FreeBSD 

• Increasing Our FreeBSD Advocacy and 
Marketing Efforts 

• Providing Additional Conference 
Resources and Travel Grants 

• Continued Development of the FreeBSD 
Journal 

• Protecting FreeBSD IP and Providing 
Legal Support to the Project 

• Purchasing Hardware to Build and 
Improve FreeBSD Project Infrastructure 


0 

FreeBSD 

FOUNDATION 


Making a donation is quick and easy. 

freebsdfoundation.org/donate 






FreeBSD)° uRNAL 

Editorial Board 


LETTER 

from the Board 


John Baldwin • 

Bryan Drewery • 

Justin Gibbs • 

Daichi Goto • 
Joseph Kong • 

Dru Lavigne • 

Michael W Lucas • 
Ed Maste • 

Kirk McKusick • 

George V Neville-Neil • 

Philip Paeps • 

Kristof Provost • 

Hiroki Sato • 

Benedict Reuschling • 

Robert N. M. Watson • 


FreeBSD Developer, Member of the 
FreeBSD Core Team and Chair of 
FreeBSD Journal Editorial Board. 

Senior Software Engineer at EMC Isilon, 
member of FreeBSD Portmgr Team, 
and FreeBSD Committer. 

Founder of the FreeBSD Foundation, 
President of the FreeBSD Foundation, 
and a Software Engineer at Facebook. 

Director at BSD Consulting Inc. 
(Tokyo). 

Software Development Engineer at 
Amazon Web Services, author of 
FreeBSD Device Drivers and Designing 
BSD Rootkits. 

Director of Storage Engineering at 
iXsystems, author of BSD Flacks and 
The Best of FreeBSD Basics. 

Author of Absolute FreeBSD. 

Director of Project Development, 
FreeBSD Foundation. 

Treasurer of the FreeBSD Foundation 
Board, and lead author of The Design 
and Implementation book series. 

Director of the FreeBSD Foundation 
Board, and co-author of The Design 
and Implementation of the FreeBSD 
Operating System. 

Secretary of the FreeBSD Foundation 
Board, FreeBSD Committer, and 
Independent Consultant. 

Treasurer of the EuroBSDCon 
Foundation, FreeBSD Committer, 
and Independent Consultant. 

Director of the FreeBSD 
Foundation Board, Chair of Asia 
BSDCon, member of the FreeBSD 
Core Team, and Assistant 
Professor at Tokyo Institute of 
Technology. 

Vice President of the FreeBSD 
Foundation Board, a FreeBSD Docu¬ 
mentation Committer, and member 
of the FreeBSD Core Team. 

Director of the FreeBSD Foundation 
Board, Founder of the TrustedBSD 
Project, and University Senior Lecturer 
at the University of Cambridge. 


S&W Publishing llc 

PO BOX 408, BELFAST, MAINE 049 1 5 


Publisher • Walter Andrzejewski 

walter@freebsdjournal.com 


Editor-at-Large • James Maurer 

jmaurer@freebsdjournal.com 


Copy Editor • Annaliese Jakimides 


Design & Production • Dianne M. Kischitz 

dianne@freebsdjournal.com 


Advertising Sales • Walter Andrzejewski 

walter@freebsdjournal.com 
Call 888/290-9469 


CHANGES 


W elcome to the May/June issue of the 

FreeBSD Journal. In this issue, we delve into 
using our favorite open-source operating 
system on one of the world's most popular 
educational computing platforms—the Raspberry Pi. 

Tom Jones kicks off things with an "Introduction to 
Hardware Hacking on FreeBSD," followed by Benedict • 
Reuschling's "Running Incinga2," which describes how 
to use FreeBSD and an RPi for systems monitoring. 

Finally, Roller Angel of the FreeBSD Foundation takes a 
step away from the RPi and explains how to run a 
Media Server using FreeBSD. 

FreeBSD is an ever-evolving, open-source project, and 
changes are committed to the code base daily, as Steven 
Kreuzer details in his farewell "svn Update" column. 

This seems like an appropriate place to thank Steven for 
writing many such excellent columns over the years. The 
project is ever changing and continues to welcome new 
developers such as Doug Moore and Sergio Carlavilla, 
both of whom are featured in Dru Lavigne's "New Faces 
of FreeBSD" column. 

The FreeBSD Journal's Editorial Board is also undergo¬ 
ing some changes. Brooks Davis and Steven Kreuzer will 
rotate off the Editorial Board, and we thank them for 
their help in recruiting authors and shepherding articles 
over the past three years. Kristof Provost joins the 
Editorial Board and has already begun helping to plan 
issues for the upcoming year. Lastly, George Neville-Neil 
is entrusting the board chair reins to John Baldwin. 

George has chaired the Editorial Board since the 
Journal's inception. The Editorial Board and the 
Foundation thank him for that and are pleased he will 
still participate as a member of the board. 

The newly configured FreeBSD Journal Editorial Board 
will continue to deliver quality articles and columns 
about FreeBSD to our growing community. Even if you 
are not an official Editorial Board member, know that 
we welcome suggestions for issue themes, articles, and 
authors to write them. 


FreeBSD Journal (ISBN: 978-0-615-88479-0) is published 6 times 
a year (January/February, March/April, May/June, July/August, 
September/October, November/December). 

Published by the FreeBSD Foundation, 

2222 14th Street, Boulder, CO 80302 
ph: 720/207-5142 • fax: 720/222-2350 
email: info@freebsdfoundation.org 
Copyright © 2019 by FreeBSD Foundation. All rights reserved. This magazine may not be 
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H ardware 
■ Hacking 


OH FraaBSD 


by Tom Jones 



FreeBSD is the perfect platform for maker and hardware 
hacking projects because we manage to offer such a solid 
and uniform support across a wide range of boards. 


F reeBSD has excellent support for many different ARM Single 
Board Computers (SBCs). Linux ships with most SBCs, and 
each SBC seems to come with its own Linux distro. 

Normally the Linux distro with the best support for your 
board is the one from the board manufacturer that leaves you with 
a fractured set of distributions and varying support for packages 
and inconsistent releases. FreeBSD does a lot better—we don't 
always have support for boards right away, but the boards we do 
support tend to give the same great experience. We have a single, 
consistent system that runs the same on all the boards we support. 
If it runs FreeBSD, it runs the same FreeBSD as on a desktop system 
This article will show you how to use FreeBSD's excellent hard¬ 
ware support to control real devices. We will do this by diving into 
how to use GPIO on FreeBSD on an ARM SBC. 

General Purpose Input/Output (GPIO) devices give us a window 
from the computer to cause a change in the real world. This is nor¬ 
mally implemented by writing to a special part of memory or using 
processor register to control something in the real world. On ARM 
SoCs, this is normally implemented using a mapped piece of memo 
ry that, when written to, allows us to control a voltage on an 
exposed pin. FreeBSD provides device drivers to allow processes in 
userspace to interact with GPIO with the same interface across all 


In this article 
we use the 
BeagleBone Black 
Single Board 
Computer. 
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supported hardware platforms. 

GPIO devices are not available on all sys¬ 
tems, but they are present on a surprising 
number. Normally, exposed GPIO can be 
spotted as pin headers on the main pcb of 
the system. If you have ever set up a pc 
engines board, you may have noticed a pin 
header labelled GPIO next to the serial con¬ 
nector. A large number of SBCs are now 
being specifically designed to export GPIO 
for use in hardware projects. There are Intel 
boards such as the LattePanda that run the 
familiar 64-bit (x86) platform. By and large, 
most of the SBCs designed for hardware 
projects run either 32-bit or 64-bit ARM architecture, such as the BeagleBone 
and Raspberry Pi families of computers. 

In this article, I am going to use the ARMv7 (32-bit) BeagleBone Black board. 
The GPIO and bus interface concepts are common to all platforms supported by 
FreeBSD and will transfer to different hardware quite easily. The BeagleBone 
Black is a nice board because it has very mature FreeBSD support and has a 
large number of 10 ports exposed for experimentation. 

To follow along with this article you will need: 

• a BeagleBone Black SBC (a different board would work, but all the GPIO 
names will be different) 

• a mini USB cable 

• an ethernet cable to connect the BeagleBone Black to the Internet 

• a small breadboard 

• some jumper wires 

• 3x resistors (something between 200 ohm and 400 ohm will be fine) 

• 3x LEDS (1 red, 1 green, and 1 orange) 


Above: The 
BeagleBone 
Black and 
components 
we use in 
this article. 


Setting up the BeagleBone Black 

The latest FreeBSD release image (12 at the time of writing) for the BeagleBone 
Black can be downloaded from the project mirror. This must be decompressed 
and written to an SD card with dd: 


$ fetch ftp://ftp.freebsd.org/pub/FreeBSD/releases/arm/armv7/ISO-IMAGES/\ 
12.0/FreeBSD-12.0-RELEASE-arm-armv7-BEAGLEBONE.img.xz 
$ xz -d FreeBSD-12.0-RELEASE-arm-armv7-BEAGLEBONE.img.xz 

# dd if=FreeBSD-12.0-RELEASE-arm-armv7-BEAGLEBONE.img of=/dev/daO bs=lm 


The location your sd card mounts will vary; be careful with the dd command 
as it will overwrite the disc at which you point it without any protection. 

Once you have prepared the SD card, you should connect the mini USB port 
of the BeagleBone Black to a USB port on your computer. This cable provides 
both power and the interface we are going to use to connect to the board. The 


May/June 2019 


5 












BeagleBone Black acts as a USB serial gadget, and through this interface the 
BeagleBone Black creates a virtual serial port. After connecting the board, 
look in dmesg for a new umodem device or in /dev for a /dev/ttyUX device (on 
the Mac OS, this device will probably be /dev/tty.usbmodemFreeBSD11). You 
should see a USB serial device, which can establish a connection from a 
FreeBSD system using the cu serial terminal in the base at a baud rate of 
115200: 


# cu -1 /dev/ttyUO -s 115200 


To exit from cu, hit enter, type (a tilde, then a full stop). Once connected 
over serial, you can get into the system with the default username and pass¬ 
word (root/root or freebsd/freebsd). 

GPIO with FreeBSD 

Once in, you can have a look around and see that this is a normal FreeBSD 
install. If you search in dmesg, you will see that four GPIO controllers have 
connected and a GPIO bus (gpiobus) and control (gpioc) interface have been 
created for each. 


gpioO: <TI AM335x General Purpose I/O (GPIO)> mem 0x44e07000-0x44e07fff irq 
7 on simplebusO 

gpiobusO: <OFW GPIO bus> on gpioO 
gpiocO: <GPIO controller> on gpioO 


There can be multiple GPIO controllers on a system. FreeBSD exposes each 
of these controllers as a separate /dev/gpiocX device. On the BeagleBone 
Black, there are four buses. 

Unlike Linux, where GPIO devices are exposed through /sys/class as files, 
FreeBSD has a command line tool (and a C library) for interacting with GPIO 
pins called gpioctl. Let's try using gpioctl to list some of the available pins on 
the BeagleBone Black. 


# gpioctl -f /dev/gpiocl -lv 


... snip... 
pin 19:0 
pin 20:0 
pin 21:0 
pin 22: 0 
... snip... 


gpio_l9<IN,PD>, caps:<IN,OUT , PU,PD,UNKNOWN,UNKNOWN,UNKNOWN,UNKNOWN,UNKNOWN> 
gpio_20<IN,PD>, caps:<IN,OUT,PU,PD,UNKNOWN,UNKNOWN,UNKNOWN,UNKNOWN,UNKNOWN> 
gpio_2l<OUT>, caps:<IN,OUT,PU,PD,UNKNOWN,UNKNOWN,UNKNOWN,UNKNOWN,UNKNOWN> 
gpio_22<OUT>, caps:<IN,OUT,PU,PD,UNKNOWN,UNKNOWN,UNKNOWN,UNKNOWN,UNKNOWN> 


gpioctl gives a list of all the pins the controller knows about. Each of the 
four GPIO controllers on the BeagleBone Black has 32 pins connected, gpioctl 
tells us several things about each pin. First, it tells us the number it uses to 
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refer to the pin. Next, the current logical level of the pin. And the final column in 
the output has the hardware name of the pin, i.e., gpio_22 and the pins' flags. 
Some controllers have more descriptive names for pins taken from the SoCs 
datasheet. 

gpioctl(8) lists the possible flags for a pin: 


IN Input pin 

OUT Output pin 

OD Open drain pin 

PP Push pull pin 

TS Tristate pin 

PU Pull-up pin 

PD Pull-down pin 

II Inverted input pin 

10 Inverted output pin 


From our gpioctl output, we can see that pin 19 is configured as an input by 
default and it has a pull down configured, while pin 21 is configured as an out¬ 
put, but could be configured as either an input or an output and could have 
either a pull-up or pull-down resistor. A pull down is a resistor added between 
the pin and ground to keep the logical level of the pin output low unless it is 
driven upwards. This will help us later. 

Pin 21 is configured as an output. If we look at the BeagleBone Black System 
Reference manual section 6.5, we see that the BeagleBone Black has four user- 
controllable LEDS called USR0-USR3 and they are connected to GPI01 21, GPI02 
22, GPI02 23, and GPI02 24. LED USRO is available for us to use, while the oth¬ 
ers are set aside for other tasks. 

https://cdn-shop.adafruit.com/datasheets/BBB SRM.pdf 


LED 

GPIO SIGNAL 

PROC 

USRO 

GPI01_21 

V15 

USR1 

GPI02_22 

U15 

USR2 

GPI02_23 

T15 

USR3 

GPI02 24 

V16 


User LED Control Signals (Table 7 from the BBB SRM, CC-SA). 

Table by Gerald Coley of BeagleBoard.org. 

For more information, see http://creativecommons.org/license/results-one?license_code=by-sa . 


In the gpioctl output, we can see that all four pins have a logical level of 0; the 
easiest way to find the LEDs on the board is to turn them on. 

Let's do that. 
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gpioctl can set the LED to a digital value of 0 
or 1. Let's configure and turn on USRO: 



# gpioctl -f /dev/gpiocl 21 OUT 

# gpioctl -f /dev/gpiocl 21 1 


Bask in the illumination of our glorious LED. 
Further we can toggle an LED by using the -t 
flag to gpioctl. This can be helpful when you just 
want to blink the LED. 


The BeagleBone 
Black has four 
USR LEDs. 

In this case, USRO 


# gpioctl -f /dev/gpiocl -t 21 

# gpioctl -f /dev/gpiocl -t 21 

# gpioctl -f /dev/gpiocl -t 21 


is illuminated.- 

Should cause the LED to turn on and off. 

Using the built-in LEDs is handy for showing status information from the 
board and for experimenting with tools, but the GPIOs that back these 
LEDs are not broken out to the pin headers on the BeagleBone Black. Let's 
do the same thing again with external LEDs. 

The BeagleBone Black has two sets of pin headers called P8 and P9. With 
the ethernet jack on the right, P8 is the bottom header and P9 is the top 
header. Most of P8 is assigned to LED pins (which can be reconfigured) and 
there are still several available GPIOs we can use. 

We are going to connect LEDs to pins 14, 16, 
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# gpioctl -f/dev/gpiocO 

-c 26 OUT 

# 

red 

# gpioctl -f/dev/gpiocl 

-c 14 OUT 

# 

orange 

# gpioctl -f/dev/gpioc2 

-c 1 OUT 

# 

green 

# gpioctl -f/dev/gpiocO 

26 1 



# gpioctl -f/dev/gpiocl 

14 1 



# gpioctl -f/dev/gpioc2 

1 1 




You should now have all three LEDs turned on. If you used three colors as I 
did, then you should have a nice red, orange, and green ready to do something 
interesting. 

A Hardware Project with FreeBSD 

FreeBSD has continuous integration (Cl) servers that build FreeBSD for different 
architectures to test commits as they are made to the tree. FreeBSD uses 
Jenkins for Cl, and Jenkins offers a handy status API that tells us how a build is 
doing and whether it succeeded or failed. 

Let's put together a build status indicator that tells us how the FreeBSD 
ARMv7 (the architecture of the BeagleBone Black) is doing. Jenkins exposes the 
build status through a json api, and textproc/jq provides a simple way to query 
json objects. Jenkins returns two fields concerning the in-progress build—'build¬ 
ing' and 'result'. If 'building' is true, then there will not be a valid 'result'. 

'result' can be 'SUCCESS' 'FAILURE' 'UNSTABLE' or 'none' depending on the 
'building' status and the 'result' of the most recent build. 


Do You Have an 
Idea for an Article? 


Write 


For Us! 

\gffree&S& 


Contact Jim Maurer 
(jmaurer@freebsdjournal.com) 
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The scripts require the jq tool to parse the json from the Cl server and we 
need a base set of ssl certificates to authenticate with the server. The 
BeagleBone Black doesn't have a real time clock—you will need to have 
accurate time to do ssl to the Cl server. 


# pkg install jq ca_root_nss 

# ntpdate -s pool.ntp.org 


#!/bin/sh 

project=FreeBSD-head-armv7-build 

# configure the leds as outputs 

gpioctl -f /dev/gpiocO -c 26 OUT # red 

gpioctl -f /dev/gpiocl -c 14 OUT # orange 

gpioctl -f /dev/gpioc2 -c 1 OUT # green 

# flash all the leds at start 

gpioctl -f /dev/gpiocO 26 1 

gpioctl -f /dev/gpiocl 14 1 

gpioctl -f /dev/gpioc2 1 1 

sleep 2 

# check the build status once a minute 
while true; do 

echo fetching $project 

output="fetch -o - https://ci.freebsd.org/job/$project/ 
lastBuild/api/json 2>/dev/null" 

building="echo $output | jq ".building"" 
result="echo $output | jq ".result"" 

# clear all leds 
gpioctl -f /dev/gpiocO 26 0 
gpioctl -f /dev/gpiocl 14 0 
gpioctl -f /dev/gpioc2 1 0 


if [ "$building" = "true" ]; then 
echo $project is building 
gpioctl -f /dev/gpiocl 14 1 # orange led 


for foo in "jot 60 1"; 
do 

gpioctl -f /dev/gpiocl -t 14 # orange led 
sleep 0.5 
done 
else 

echo $project done building 
if [ "$result" = '"SUCCESS"' ]; then 
echo build suceeded for $project 
gpioctl -f /dev/gpioc2 1 1 #green led 
else 

echo build failed for $project 
gpioctl -f /dev/gpiocO 26 1 #red led 
fi 
fi 


sleep 60 #1 minute 

done 
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Tom Jonas is a founder and director of a Hackerspace in 
Aberdeen, Scotland (57northhacklab.orq.uk) . He started 
hardware hacking on FreeBSD trying to port a project from 
Linux and got sucked into the world of kernel hacking. 



We can connect three LEDs to GPIO on the BeagleBone Black—a 
green, a red, and an orange one. The listing blinks the orange LED 
when the build is running, the green LED blinks 
when the build is passing, and the red LED blinks 
when the build fails. 

Using LEDs is just an example. We could equally 
connect a relay to control a siren to the GPIO 
enabling the red LED to wake us up when the build 
starts to fail.* 


BeagleBone Black 
connected to our 
three status LEDs. 


Thank you! 

The FreesBSD Foundation would like to 
acknowledge the following companies for 
their continued support of the Project. 
Because of generous donations such as 
these we are able to continue moving the 
Project forward. 
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bv Roller Anoel 


Media Servers are wonderful additions to a net¬ 
work. They allow all kinds of player devices to find 
them and stream the media off the media server. 


hat does it take to turn a standard FreeBSD RELEASE system into 
a fully functional media center? It's actually pretty straightfor¬ 
ward. First, you must decide what server you will be installing. 
There are a few I can recommend. Plex Media Server would be 
my first choice as its fully-featured interface is a joy to use. To install it, you 
only need to type sudo pkg install -y plexmediaserver. Plex does 
offer a Plex Pass for a fee that allows additional features and there is a dif¬ 
ferent command to use if you have that, which is sudo pkg install -y 
plexmediaserver-plexpas s. 

The next choice for a decent media server is Emby. The command for 
that is sudo pkg install -y emby-server. Finally, you can just install 
a mini DLNA server. Since Plex includes its own built-in DLNA server in addi¬ 
tion to its own server software, I have mainly just stuck to using that 
DLNA server. However, those looking for something simple can just type 
sudo pkg install -y minidlna. Many players have built-in support 
for locating and streaming media from DLNA servers. It's important to read 
the information displayed after installing a package. To pull up that infor¬ 
mation again, type pkg info -D and the name of the package. If you 
want the media server to automatically start when FreeBSD is started, make 
sure you add an entry in your /etc/rc.conf. 

Configuration 

After installation you need to do some configuration. This is mainly just 
telling the server software where it ought to look for the different media 
types on your hard drive. Provide the software with the folders, and it will 
do a scan to not only bring the files into the system so they can be served, 
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but it will also try to match any additional information about the files with data 
from the Internet. For instance, if one of your files was the movie Tron: Legacy in 
the Movies folder named tron.mkv, Plex would see that, and instead of showing 
that filename, the listing for Tron in the Plex interface is lovely and filled with 
movie posters, actor names, descriptions, and many more features. Plex and 
Emby have additional applications that can be installed on mobile phones and 
smart TVs to allow one to access their media servers from these devices as well 
and not just from the web interface. 

I'll walk you through configuring Plex Media Server as it's the one I use 
most often. With other media servers, the process is very similar. By the way, 

I'm running Plex on the same AMD64 desktop machine from the January/ 
February 2019 FreeBSD Journal article I wrote called A Guide To Getting Started 
with FreeBSD. Once installed, I usually like Plex to start up on boot so I type 
sudo sysrc plexmediaserver_plexpass_enable=YES. As you can see, I have 
a Plex Pass. I mainly use it, so I can sync media from my server to my Android 
when I want access to media offline. I also find the movie trailer feature handy as 
I can quickly watch a trailer to see if I feel like watching a particular movie that I 
haven't seen before. 

Next I need to start up Plex, so I type sudo service plexmediaserver_ 
plexpass start. Now that Plex is running, I open the following URL in a web 
browser on the same network as my media server; keep in mind my IP is proba¬ 
bly different from yours, but the port and path should be the same— 
172.16.28.2:32400/web. Once on that page, I just need to sign into my Plex 
account, and I can tell Plex that I like to keep my music type of media in the 
/mediacenter/Music dataset, movie type of media in the /mediacenter/Movies 
dataset, and the TV show type of media in the /mediacenter/Tv Shows dataset. 
Once I've set up a few types of media and finished the welcome wizard, Plex will 
scan all the media and match any media it can with media it knows about from 
the Internet. If Plex guesses wrong, I can un-match and use the interface to see 
what similar matches it can find, or I can simply provide my own content like 
posters, titles, and descriptions. 

For the older TVs in the house, I have a Google Chromecast plugged in. I can 
use the Plex application on my Android phone to cast any of the media files to 
the TV. For my newest TV, the Samsung Smart TV, I can just go to the app store 
on the TV and install Plex to use it directly with the remote control to stream any 
media file. When I drive to work, I have my music synced to my Android so I can 
just play that media in offline mode to save data while not on WiFi. If mobile 
data limits aren't an issue, consider setting up OpenVPN at the house so that a 
remote connection to your media server can easily be made over the VPN from 
the device. If you're not keen on setting up a VPN, Plex does offer to allow media 
access outside of the network and has plenty of good information online for set¬ 
ting it up. I prefer to use a remote access VPN to access machines at home. 



Jails 

Consider running your media server in a jail. Michael W Lucas has a wonderful 
new book for helping master jails, https://mwl.io/nonfiction/os#fmjail , and it 
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explains all the benefits and features of jails. There's also a good tip in there 
that should be implemented on media servers. It has to do with speeding 
up Python on FreeBSD. Apparently, mounting /dev/fd in your /etc/fstab 
speeds up Python. Great! All you do is add an entry into your /etc/fstab 
that looks like the following: 


fdescfs /dev/fd fdescfs rw 0 0 


ZFS Datasets 

Also consider how you will be working with your files from the media server. Is 
the delete option in the media server interface important? Then the application 
will need to have permission to read and write to your media files. You may be 
able to get away with having a server with only read access to the media files if 
you want to do it that way. Consider using ZFS datasets for each media type. 
With separate datasets, you can experiment with ZFS to see how optimized 
you can make the storage depending on the typical media attributes. A movie 
file is usually a big file; audio files aren't usually large, but this can obviously 
vary. And it's the same with photos. Knowing the typical file size will help you 
when tuning ZFS datasets. See the FreeBSD Handbook for a great resource on 
ZFS and dig deeper with ZF Sbook.com . • 


Roller Angel is an avid BSD user who enjoys all the amazing things that can be done with BSD technol¬ 
ogy. Fie has taught programming workshops based on FreeBSD and is working on building an online training 
platform for teaching BSD and related technologies. See BSD.pw for more information. 
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In my day job, I am responsible for a 40-node, 
big data cluster used in education and research 
at the Darmstadt University of Applied Sciences, Darmstadt, 
Germany. One of the tasks of a sysadmin is checking whether 
the systems you are responsible for are healthy and available 
on the network. 


T his is typically done using periodic checks from a monitoring 
instance that collects data from remote machines and uses the 
metrics to trigger alarms when certain thresholds are reached. 
We monitor the cluster nodes from the central file server, which 
can spare a few cycles when it is not serving files to clients (ZFS-based 
NFSv4 exports for home directories and other shared data). 

Another sysadmin job is thinking about the "what-could-go- 
wrong" scenario. That scenario might never happen, but when and if 
it does, you are glad to have already implemented a "better-safe- 
than-sorry" scenario. The situation here is "who is watching the 
watcher?"—what will happen if the central monitoring instance goes 
down? It could very well be that the outage is not recognized for a 
while, which would also not inform us of any other failures occurring 
in the meantime. When that happens, we not only have to deal with 
one but two problems: the unavailable monitoring system and the 
problem that the monitoring should have told us about. We quickly 
came to the conclusion that a second system needs to monitor the 
main monitoring server and alert us if that system disappears from 
the network without running other checks itself (which is optional). 
Ideally, this should be done from a separate network. If both systems 
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were on the same subnet, we would not get any information from our two 
monitoring systems if that whole network became unreachable. Of course, a 
second system just for the sake of monitoring is expensive (both the initial 
investment and running costs like electricity), so we needed to find a low-cost 
solution. 

The Raspberry Pi is the perfect tool for long-term, 24/7 monitoring. With the 
small form factor, low power use, and a powerful enough CPU for periodic 
checks of remote systems, it can solve a variety of tasks. With a small initial 
cost (the board itself, a compact flash card, and some cables) it is easy to get 
started, although some tasks like processing package updates may take a bit 
longer than on an amd64 system. Compiling things locally on the RPi3 takes 
much longer, hence we rely on packages for our third-party software needs. 

First, we download the FreeBSD-12.0-RELEASE-arm64-aarch64-RPi3.img.xz 
from the SD Card Images section in the download area of freebsd.org. After 
un-xz-ing the archive, it is time to insert the SD card (we use one with 64 GB; 
smaller ones also work perfectly fine) into the reader on the machine that was 
downloading the image. The following command line will copy the image to 
the SD card (change device names to match; take care not to overwrite a dif¬ 
ferent partition): 



# dd if=/FreeBSD-12.0-RELEASE-arm64-aarch64-RPl3.img of=/dev/disk2\ 
bs=lm conv=sync 


Once dd(1) has finished writing the image, unmount it and insert it into the 
RPi3's SD card slot. Connect all the other peripherals like monitor, keyboard, 
network cable, and power. The Pi should start booting once the power is con¬ 
nected. The first boot will take a bit of time to expand the image according to 
the size of the SD card. Be patient—this will only be done once and subse¬ 
quent boots will run faster. There are two users that you can log in with by 
default: root and freebsd, with the same password as the username, respec¬ 
tively. This is the first thing you should change after logging into the Pi for the 
first time. Then it is time to do some initial system configuration based on your 
needs and environment. 

You may have heard that writing to the SD card constantly will reduce the 
lifetime as there are only so many rewrite cycles that the cells that make up 
the storage media can take. To avoid an early death, we attached a cheap 32- 
GB SSD to it and create a ZFS pool on it. Running ZFS on an embedded device 
is generally discouraged and UFS is a perfectly fine filesystem for those kinds 
of devices. Surprisingly enough, we've been running this setup for months 
now without any problems. Granted, the zpool is not redundant and the 
writes on the pool are not as heavy as on our big data file server. Your mileage 
may vary, and additional tuning may be required. Here is the ZFS list output to 
show which datasets were created: 
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ssd 

22.4G 

6.42G 

22.5M 

/ssd 

ssd/swap 

1.03G 

6.45G 

l.OOG 

- 

ssd/tmp 

41.6M 

6.42G 

41.6M 

/tmp 

ssd/usr 

1.44G 

6.42G 

1.44G 

/usr 

ssd/usr/ports 

1.08G 

6.42G 

1.08G 

/usr/ports 

ssd/var 

10.8G 

6.42G 

10.5G 

/var 

ssd/var/cache 

860K 

6.42G 

860K 

/var/cache 

ssd/var/db 

252M 

6.42G 

252M 

/var/db 

ssd/var/log 

34.8M 

6.42G 

34.8M 

/var/log 


We are still booting from UFS, but the main, write-heavy filesystems like 
/usr and /var reside on the SSD pool. This is as simple as creating the 
datasets (activating lz4 compression in the process) and copying the directory 
contents from UFS before setting a mountpoint. Take extra precautions when 
mounting /usr as this will mount the ZFS dataset /usr over your current sys¬ 
tem, which will likely cause some interruptions. To prevent that and let the Pi 
boot properly, I have the following lines in my /etc/rc. local: 


/sbin/zpool import -f ssd 
/sbin/zfs mount -a 
swapon /dev/zvol/ssd/swap 
/usr/sbin/ntpdate -b de.pool.ntp.org 


As you can see, I'm also running the swap from the SSD and sync my time 
upon reboot from a timeserver near me. For the sake of completeness, these 
are my entries in /boot/loader .conf: 


# Configure USB OTG; see usb_template(4). 
hw.usb.template=3 

#umodem_load="YES" 

# Multiple console (serial+efi gop) enabled. 
boot_multicons="YES" 

boot_serial="YES" 

# Disable the beastie menu and color 
beastie_disable="YES" 
loader_color="NO" 
geom_label_load="YES" 
verbose_loading="YES" 
autoboot_delay="2" 

zfs load="YES" 


The /etc/rc.conf is fairly minimalistic and only has a few changes in it: 


hostname="rpi3.mydomain.local" 
ifconfig_DEFAULT="DHCP" 
sshd_enable="YES" 
sendmail_enable="NONE" 

Code continues 
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Continued 

sendmail_submit_enable="NO" 

sendmail_outbound_enable="NO" 

sendmail_msp_queue_enable="NO" 

growfs_enable="YES" 

keymap="de.kbd" 

hostid_enable="YES" 

fsck_y_enable="NO" 

background_f sck="no" 

mixer enable="no" 



Reboot to see that the Pi will come back up to the login prompt without 
any errors and that ssh logins are possible. This is an important step to run¬ 
ning the Pi headless without a monitor attached to it. 

Since we want the RPi3 to send us notifications if our monitoring system 
detects anything unusual, we configure SSMTP. This provides us with a simple, 
send-only mail delivery system. For this article, we use Google mail to deliver 
email. Be aware of the sensitive nature of the emails you are sending, so 
Gmail might not be the best solution for all environments. Replace it with 
your own mail delivery that you know and trust to ship messages about any 
system problems you might encounter. 

First, we need to install the ssmtp package: 


# pkg install ssmtp 


The configuration file is located in /usr/local/etc/ssmtp/ and we need 
to modify two files here (create them if they do not exist yet or copy the .sam¬ 
ple files of the same name and modify them): ssmtp.conf and revaliases. 
In ssmtp.conf, we need only to have the following lines present: 


root=yourusername@gmail.com 

mailhub=smtp.gmail.com:587 

AuthUser=yourusername@gmail.com 

AuthPass=thepasswordforthegmailaccount 

UseSTARTTLS=YES 

rewriteDomain=gmail.com 

hostname=rpi3.mydomain.local 

FromLineOverride=YES 

UseTLS=YES 


The revaliases file has just two lines in it: 


root:yourusername@gmail.com:smtp.gmail.com:587 
otheruser:yourotherusername@ gmail.com:smtp.gmail.com:5 8 7 


This will configure the local mapping to determine which local user should 
get mail delivered. At least root and an unprivileged account should be con¬ 
figured here. Periodic system mail is sent to root by default and the email 
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address after defines where that should be delivered. The same is true for per¬ 
sonal mail to that unprivileged user in the line below it. The mailer.conf in 
/etc should have the following lines in it (likely done by the port/package): 



#sendmail 

#send-mail 

#mailq 

#newaliases 

#hoststat 

#purgestat 

sendmail 

send-mail 

mailq 

newaliases 

hoststat 

purgestat 


/usr/libexec/sendmail/sendmail 
/usr/libexec/sendmail/sendmail 
/usr/libexec/sendmail/sendmail 
/usr/libexec/sendmail/sendmail 
/usr/libexec/sendmail/sendmail 
/usr/libexec/sendmail/sendmail 
/usr/local/sbin/ssmtp 
/usr/local/sbin/ssmtp 
/usr/local/sbin/ssmtp 
/usr/local/sbin/ssmtp 
/usr/bin/true 
/usr/bin/true 


Make sure that ssmtp owns the directory var/spool/clientmqueue using chown: 


# chown -R smmsp:smmsp /var/spool/clientmqueue 

# chmod -R 0775 /var/spool/clientmqueue 


Test the mail setup by sending yourself a test message as the root user and the 
unprivileged user. You may need to allow unsecure applications in your Google 
account settings to enable mail transport. When mail is arriving, the configura¬ 
tion for Icinga2, the monitoring system we are using, can commence. 

Packages for Icinga2 need to be installed first, including PostgreSQL and the 
necessary PHP libraries for nginx, which we'll use as the Webserver to run the 
Icingaweb2 front-end. 


# pkg install icinga2 icingaweb2 postgresql95-server nginx 
ImageMagick6-noxll php72-pecl-imagick 


We enable the icinga service and postgresql to run upon reboot. Do not start 
these services just yet as they are still unconfigured: 


# sysrc icinga2_enable=yes 

# sysrc postgresql_enable=yes 


Configuring PostgreSQL as a backend database is the next task. Since we are 
running on the SSD, the database can benefit from some tuning for ZFS. Note 
that this is not strictly needed and postgres will run just fine on UFS. 

A dataset called pgdata is created, some properties are set, and ownership of 
the mountpoint is changed to the pgsql user: 


# zfs create -o mountpoint=/usr/local/pgsql/data ssd/pgdata 

# zfs set recordsize=8k ssd/pgdata 

# zfs set logbias=throughput ssd/pgdata 
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Continued 

# zfs set redundant_metadata=most ssd/pgdata 

# zfs set primarycache=metadata ssd/pgdata 

# chown pgsqlrpgsql /usr/local/pgsql/data 



The next steps are done as the pgsql user, either by switching to it using 
su( 1 ) or (when configured) via sudo -u pgsql. 


pgsql$ cd 

pgsql$ initdb —no-locale —encoding=utf-8 —lc-collate=C -E UTF8 -D ./data 
psql$ pg_ctl start -D ./data 


This will initialize the database cluster and start the database using pg_ctl. UTF- 
8 is set as the encoding for the database as Icinga requires it. Once the postgresql 
service is running, a user and database called icinga is created: 


pgsql$ createuser -dPrs icinga 

pgsql$ createdb -0 icinga -E UTF8 icinga 


To allow this user to access the database, the following lines need to be added 
to /usr/local/pgsql/data/pg_hba.conf: 


local icinga icinga md5 
host icinga icinga 127.0.0.1/32 md5 
host icinga icinga :: 1/128 md5 


Icinga is using its own database schema to store tables for hosts, services, users, 
notifications, etc. These need to exist before Icinga can start monitoring. An SQL 
script is provided to set up the database using psql: 


pgsql$ psql -U icinga -d icinga < /usr/local/share/icinga2-ido-pgsql/ 
schema/pgsql.sql 


Subsequent updates of the Icinga package/port will require updates to the data¬ 
base schema as well. These updates are located under /usr/iocai/share/ 
icinga2-ido-pgsql/schema/upgrades and must be applied in order. Check 
the update instructions on the Icinga website for details. After the schema has 
been set up in the database, log out of the pgsql user. 

Like nginx, Icinga has a plugin-like system to activate certain features. Our setup 
requires the activation of at least the ido-pgsql (since we are using that as the 
backing database) and command (to, i.e., schedule service checks through 
Icingaweb2) modules. The api feature will replace the command module in the 
future, but for now, we activate it to be on the safe side. 


# icinga2 feature enable ido-pgsql api command 


To tell Icinga about the postgresql database details, the ido-pgsql.conf file 
located in /usr/local/etc/icinga2/features-enabled/must contain the 
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following lines: 


object IdoPgsqlConnection "ido-pgsql" { 
user = "icinga" 

password = "thepasswordyousetwhencreatingthedatabaseabove" 
host = "localhost" 
database = "icinga" 

} 


Run the command icinga api setup and modify /usr/local/etc/ 
icinga2/conf .d/api-users .conf to set up a separate API user for 
icingaweb2: 


object ApiUser "icingaweb2" { 

password = "somerandompasswordstrongerthanthisone" 
permissions = [ "status/query", "actions/*", "objects/modify/*", 

"objects/query/*" ] 

} 


The permissions allow certain actions to be performed by that user. Other API 
users are possible for different actions that may have fewer privileges. This is 
beyond the scope of this article, but details can be found in the Icinga2 documen¬ 
tation (https://icinga.com/docs/) . 

Time to restart our database and bring up icinga2: 


# service postgresql restart 

# service icinga2 start 


Configure nginx as the Webserver for icingaweb2. The following steps are 
required for that: 

# sysrc php_fpm_enable=yes 

# sysrc nginx_enable=yes 

# sed -i ' ' "s/listen\ =\ 127.0.0.1:9000/listen\ =\ \/var\/run\/php5- 
fpm.sock/" /usr/local/etc/php-fpm.d/www.conf 

# sed -i '' "s/;listen.owner/listen.owner/" /usr/local/etc/php- 

fpm.d/www.conf 

# sed -i '' "s/;listen.group/listen.group/" /usr/local/etc/php- 
fpm.d/www.conf 

# sed -i '' "s/;listen.mode/listen.mode/" /usr/local/etc/php-fpm.d/www.conf 


Add the following section to nginx configuration file located in 
/usr/local/etc/nginx/nginx. conf before the location / { ... } part: 


location ~ A /icingaweb2/index\.php(.*)$ { 
fastcgi_pass unix:/var/run/php5-fpm.sock; 
fastcgi_index index.php; 
include fastcgi_params; 

fastcgi_param SCRIPT_FILENAME /usr/local/www/icingaweb2/public/index.php; 

Code continues 
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Continued 

fastcgi_param ICINGAWEB_CONFIGDIR /usr/local/etc/icingaweb2; 
fastcgi_param REMOTE_USER $remote_user; 

} 

location ~ A /icingaweb2(.+)? { 

alias /usr/local/www/icingaweb2/public; 
index index.php; 

try_files $1 $uri $uri/ /icingaweb2/index.php$is_args$args; 

} 



Note that setting up SSL is beyond the scope of this article but is fairly straight¬ 
forward with services such a letsencrypt. 

Create a php.ini from the provided php.ini-production file that came with the 
package: 


# cp /usr/local/etc/php.ini-production /usr/local/etc/php.ini 


Edit the file and set the date.timezone line to the time zone of the server. 
The Webserver and php-fpm can start now: 


# service nginx start 

# service php-fpm start 


Take a browser and point it to the IP/DNS name of your RPi3 and add /icin- 
gaweb2/setup at the end. The icingaweb setup is protected from drive-by 
attackers by a token that needs to be created from the command line like this: 


# icingacli setup token create —config=/usr/local/etc/icingaweb2 

# chown -R wwwiwww /usr/local/etc/icingaweb2 


Follow the setup steps and provide the postgresql database information (user- 
name, password) when prompted. Lars Engels, who maintains the icinga2 port 
has a blog post that will walk you through the setup (http://lme.postach.io/post/ 
installinq-icinqa-web-2-with-apache-2- 4 -icinqa-2-and-mysql-on-freebsd) . 

Configure hosts and services to monitor: 

Icinga checks are divided into active and passive checks. The active checks are 
executed on the monitored hosts themselves, and the results are sent back to the 
icinga server for further processing. Passive checks are done by the icinga server 
from outside of the hosts like ping. We'll only cover passive checks; however, 
active checks are also working well enough on the Raspberry Pi. The configura¬ 
tion file for the hosts to monitor is located under /usr/iocai/etc/icinga2/ 
conf .d/hosts, conf and my default already contains the icinga server itself. 
Simply add a new host using the following template: 


object Host "myhost" { 
import "generic-host" 
address = "ip.address.of.myhost" 


Code continues 
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Continued 



} 


vars.notification["mail"] = { 
groups = [ "icingaadmins" ] 

} 


Before restarting icinga, make sure to let it check the configuration file before 
restarting the service: 


# icinga2 daemon -C && service icinga2 restart 


The host should now appear in the icingaweb2 GUI. The Raspberry Pi will con¬ 
tinue to contact the host periodically and send alerts if a host or service is chang¬ 
ing its state from UP to DOWN or vice versa. 

Icinga offers a lot of functionality. Depending on the number of hosts and serv¬ 
ices to check, the RPi3 might need some time to process those. For a small num¬ 
ber of hosts/services, this should not become problematic and is a cost-effective 
solution with a lot of customization options. • 


liiodict liuschllig joined the FreeBSD Project in 2009. After receiving his full documenta¬ 
tion commit bit in 2010, he actively began mentoring other people to become FreeBSD commit¬ 
ters. He joined the FreeBSD Foundation in 2015, where he is currently serving as vice president. 
Benedict has a Master of Science degree in Computer Science and is teaching a UNIX for soft¬ 
ware developers class at the Darmstadt University of Applied Sciences, Darmstadt, Germany. 
Together with Allan Jude, he is host of the weekly BSDNow.tv ( http://BSDNow.tv ) podcast. 
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riot letters 

V ■ dr m by Michael W Lucas 


Dear Letters Column Person, 



I keep hearing about FreeBSD sysadmins doing fun things at 
work, but here I am just running servers and getting a paycheck, 
day in and day out. How do I make things exciting? 

Bored Stupid 


Mr. Stupid, 

No, that's making a bad assumption. You could very well be Missus 
Stupid, or Miss Stupid. My apologies. 

You stop being bored by setting sail on the Sea of Ignorance. 

The world is full of exciting stuff, like rockets and panthers and mold 
and that woman on the street corner who you think is a wacked-out 
street preacher with a brain fried by a cornucopia of illicit substances but 
is actually smarter than both of us combined and is deliberately bawling 
out the secrets of the cosmos in a manner that nobody will believe 
because it makes her giggle. 

It's no good to say, "I want to learn how to put FreeBSD on a Raspberry 
Pi," because that's not hard. You'll struggle with it for a few hours. You'll 
swear. You'll curse everyone even tangentially involved in the process. 

Then it'll be done, and you'll realize that it's boring. 

The problem is, you lack ambition. You stepped into a puny little puddle 
of ignorance, something solvable in an afternoon. A puddle isn't big 
enough. You need to set yourself adrift in your own ignorance, floating 
on a makeshift raft of your own knowledge, and desperately scrabble 
facts out of the ocean to shore up your raft until you can muddle your 
way to a destination you can only vaguely see. Did the Vikings say, "Hey, 
we're gonna discover America 500 years before that dolt Columbus!" 
before hopping in their leaky oversized canoes? No! They grabbed their 
delusions of grandeur and set sail for the edge of the world, gleefully 
ignorant of the fact that it had already been discovered by the millions of 
people already living there, all with the vague hope that a millennium 
later they'd appear on the cover of Time Magazine. 

See, magazines were sheets of paper folded and stapled together, with 
web pages printed on them. 

Sigh. Paper is trees, ground up real fine and—look, this is what 
Wikipedia's for; check it out on your own time. Before the day's out I've 
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got to get this column done and get with my attorney about that third 
lawsuit from the Avocado Liberation Front. 

The point is, computers aren't the thing to do. 

Computers are tools that let you do things. 

This is why I don't own a 3D printer. They're nifty tools, but only tools. I 
don't have a goal that demands I own and master that tool. When I fin¬ 
ish designing my "128 Most Loathed People in Computing" action fig¬ 
ures, I'm better off hiring someone else to print them. (I'm still trying to 
trim the list down to 256, let alone 128, so it'll be a while yet. And don't 
worry, you're still on the list.) 

If you're just feeding the operating systems and cleaning their cages 
and waiting for the vet to show up and replace those shoddy hard drives, 
you're not a geek. 

You're a stable hand. 

Stable hands are always bored. 

Stable hands can make a good living. Most people's dignity won't allow 
them to shovel server droppings all day. If that's all you're doing, of 
course you're bored. 

Set yourself a goal that you have no idea how to reach. Chances are 
that'll involve a computer. Sure, put FreeBSD on a Raspberry Pi, fine, but 
then wire it into your car to control a laser so you can persuade that 
chronic tailgater that he really wants to pull over and protect his remain¬ 
ing eye. Or you could do something legal, like assemble your own home 
automation system. Whatever. 

Throw yourself onto the Sea of Ignorance with only a vague idea of 
how to cross it. You'll sieve out all sorts of facts on the way and have the 
joy of assembling them into skills, into results, into things. You might 
fail—you probably will fail—most people fail at most things—but keep 
trying. Even when—er, if, I meant if—you fail, you'll discover things on 
the way. Not all of them will be related to FreeBSD, sure, but you'll accu¬ 
mulate sysadmin skills along the way. FreeBSD has all sorts of features 
that support such endeavors. 

And you won't be bored. 

None of this is related to your job, of course. Because if your job was 
exciting, they wouldn't have to pay you so much to do it. Learning all 
these skills will get you a better job, though. A differently boring job. 

All I know is, I didn't get the job of answering your letter by being 
bored. No! As a callow youth, I ate my way through 300 boxes of Captain 
Crunch cereal questing for a whistle so I could earn a visit from the FBI. I 
first installed FreeBSD because I wanted to have a truly private email server, 
which illustrates just how much ignorance I still had left to cross. 

I sincerely look forward to watching you splash around in your efforts 
to accomplish something meaningful with your life. 
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Dear Letters Column Person, 

No, I mean, I have everything running perfectly and so I only need to do 
real work about two hours a day. And the boss won’t let me play MMO 
games in the downtime. 

Not Stupid, Just Bored 

Dear Boring, 

So sorry, my mistake. Obviously, that's what you meant. 

Put your laptop in text console mode. Run tcpdump on one virtual termi¬ 
nal. Play Nethack in the other. When the boss comes up, flip to the other 
terminal and keep staring like you're interpreting packets in real time. 
When queried, keep staring blankly and inform him you're watching for 
possible IPSec-over-DNSSEC terabit Ethernet HTML 5 truncation flux. 
You're clearly right where you need to be. • 


Michael W Lucas is the author of Absolute FreeBSD, FreeBSD Mastery: 
Jails, and a bunch of other books. He’s still seeking something useful to 
do with his life. Send your questions to letters@freebsdjournal.com if 
you’re bored stupid. 
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tasks boring. 

• Delegate filesystem privileges to users. 

• Containerize ZFS datasets with jails. 

• Quickly and efficiently replicate data between 
machines. 

• Split layers off of mirrors. 

• Optimize ZFS block storage. 

• Handle large storage arrays. 

• Select caching strategies to improve performance. 

• Manage next-generation storage hardware. 

• Identify and remove bottlenecks. 

• Build screaming fast database storage. 
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by Conor Beh 


LinuxFest Northwest 2019 

There was a great turnout from the FreeBSD community for the 
20th Anniversary of LinuxFest Northwest, April 26 to 28.1 had the 
chance to join our friends in the Linux camp and open-source 
community for three FreeBSD-related talks and a large table pres¬ 
ence at the conference. Despite LinuxFest Northwest’s somewhat 
out-of-the-way location, the diversity of talks and the low-stress 
atmosphere attracted people from all over the world. 



L inuxFest Northwest 2019 kicked off bright and early Saturday morning with 
the opening of the expo hall. Two Washingtonians, myself and Jason Barbier, 
staffed the table. Joining us from farther afield were FreeBSD Foundation 
Executive Director Deb Goodkin, Core Team member Sean Chittenden, and 
Oregonians Michael Dexter and Rodney Grimes. Several other community members 
also made their presence known, and many productive discussions were enjoyed. 
Staffing the table gave me an opportunity to both interact with the community at 
large and talk to people who were not aware of FreeBSD's presence in open source. 
Later that day, I attended a talk on the security repercussions of out-of-band man¬ 
agement systems. No matter how good the security of the operating system, a chip 
right on the mainboard of the system can ruin the system in a heartbeat. A link to 
the talk can be found here. Sadly, I missed Jon "Maddog" Hall's talk titled Fifty Years 
of Unix, Internet, and More. I heard the talk was a resounding success and covered 
several instances of early BSD history. 

We wrapped up the evening with some great dinner conversations. The next 
morning, I gave the first of three FreeBSD talks presented this year. FreeBSD at Work: 
Building Network and Storage Infrastructure with pfSense and FreeNAS was a 
resounding success. I had a lot of fun presenting for the first time and the communi¬ 
ty made it a great experience. Shortly after, came Michael Dexter's talk, FreeBSD is 
Everywhere, which was extremely well received and covered some great points on 
the importance of the project. In the early afternoon, Allan Jude gave a talk on 
OpenZFS: The Best Filesystem for Every OS. His talk covered the wonders of OpenZFS 
and why it truly is an excellent cross-platform filesystem. Sadly, the venue for this talk 
filled up extremely fast and I was unable to attend in person. A video will hopefully 
be posted soon. 

Attending LinuxFest Nortwest as a presenter was a tremendous experience. The 
community-driven component of the conference was both humbling and inspiring 
for me as someone who came straight from the Microsoft world to FreeBSD. Like 
many others, I am glad that events like this exist. I extend my thanks to the FreeBSD 
Foundation for their support of my attendance, FreeBSD cofounder Rodney Grimes, 
and my friend and mentor Michael Dexter. • 


Coner Beh is a student in Washington state. Conor has an interest in FreeBSD 
system administration and storage and virtualization infrastructure. 
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BY DRU LAVIGNE 



This column aims to shine a spotlight on contributors who 
recently received their commit bit and to introduce them to 
the FreeBSD community. In this installment, the spotlight is 
on Doug Moore, who received his src bit in April, and 
Sergio Carlavilla, who received his docs bit in May. 


Tell us a bit about yourself, your background, and your interests. 

• Doug: Being a smart kid, growing up in Texas, I never really consid¬ 
ered anyplace but Rice University, and I've been circling around it ever 
since. I got a CS PhD somewhere else and came back to Rice to lurk at 
the lower fringe of an academic career. Then some Rice folks launched 
a startup and I jumped in, which led me to work for Cisco two acquisi¬ 
tions later. After that played out, I went back to lurking at Rice. 

I'm interested in fast computing for discrete math problems. I wrote 
code for sorting points along a multidimensional Hilbert curve and for 
finding the next point on the curve after a given point to enter a box. I 
think it's a great way to manage and search multidimensional data. I 
wrote some code for doing arithmetic in a fixed-size version of 
Gosper's continued logarithms, which is way better than floating point, 
since it allows you to represent concepts like 1/3. But these have 
remained private amusements so far, with the world not buying in yet. 

• Sergio: My name is Sergio Carlavilla. I was born and raised in 
Valencia (land of the "Fallas"), Spain. 

I currently work as full stack developer (Angular/Java) at 
ViewNext/IBM. In my spare time, I like to program in C/C++ and I'm the 
current maintainer of QtEmu. 

When I am away from the PC, I like to walk, read history books, and 
cook. I really love cooking. I also like traveling in Europe as I think it's 
a continent with a lot of history and wonderful landscapes. 

My interest in FreeBSD lies in the text-processing tools like our 
Sergio bsdgrep, cat, etc. 

Carlavilla . 

How did you first learn about FreeBSD and what about FreeBSD 
interested you? 

• Doug: I met Alan Cox when he became a Rice professor, and he's 
been a longtime FreeBSD committer. He started the company that I 
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joined, using FreeBSD as the basis for a web-caching software product. I 
attended several FreeBSD meetings with him and wished that I had something 
to do while everyone around me was talking FreeBSD. I was interested in help¬ 
ing, but it seemed doing anything required specialized knowledge I didn't have. 
• Sergio: The first time I heard anything about FreeBSD was when I was in net¬ 
work class and we were studying the TCP/IP protocol. The professor explained 
that the best implementation of the protocol was in the FreeBSD operating sys¬ 
tem. Afterwards, I saw that other operating systems have taken ideas from 
FreeBSD, owing to its good documentation and its robustness. What interests 
me most about FreeBSD is its good documentation and the fact that it is distrib¬ 
uted as a complete operating system. Everything is built at the same time; it's 
not a puzzle. 


How did you end up becoming a committer? 

• Doug: Alan pointed out a bit of FreeBSD code he was working on and asked 
if I had any ideas. I thought I could write something better than what was 
there, without knowing anything more than a few C-language tricks and a few 
data structures, so I did. After repeating that a few times, Konstantin Belousov 
suggested that I become a committer, so that I might stop nagging him and 
Mark Johnston to commit my changes. So now I nag them for code reviews 
instead. 
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• Sergio: Well, as I said before, I'm very interested in documentation. As a 
programmer, when I use an operating system, a tool, or a framework, I like it 
to have a good documentation and I like to understand how it works. 

I became interested in translating FreeBSD into my language, Spanish. I 
started to translate articles and then send the translations to @gabor for vali¬ 
dation and to commit the articles into the FreeBSD repository. In the following 
months, @gabor proposed me for a commit bit so I would be able to perform 
the commits myself. 


How has your experience been since joining the FreeBSD Project? Do 
you have any advice for readers who may be interested in also becom¬ 
ing a FreeBSD committer? 

• Doug: I screwed up my first big commit, and then I screwed up fixing it. 
People seem pretty forgiving if your intentions are good and you make sure 
to let them know what's going on. A screwup and a mystery together will 
annoy people. A newcomer just needs to be patient; your mentor may be a 
roadblock to you, but you are just one of a dozen FreeBSD-related tasks to 
your mentor, so be patient. 

• Sergio: My experience since joining the FreeBSD Project is very positive. The 
reception by the community has been great. We are currently trying to imple¬ 
ment a new way to translate the FreeBSD documentation, so stay tuned. 

As for tips for people interested in participating in FreeBSD I would say: 

• Take an area that you think you can improve (src/docs/ports) and make the 
necessary changes. 

• Talk to the community. Luckily, the FreeBSD community is very open and 
willing to help. 

• Be patient. Do not despair if a developer is slow to respond; the FreeBSD 
Project is made up of volunteers. 

• And finally, it should be fun. 


DRU LAVIGNE is a FreeBSD doc committer and the author of 
BSD Hacks and The Best of FreeBSD Basics. 


Contact walter@fbsdjournal 
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BSD CERTIFICATION GROUP 

HAS JOINED WITH LPI. 



ONE MORE STEP TOWARDS A 

FREE a* OPEN 

SOURCE WORLD 

NOT TO MENTION, JOBS! 

Now as a part of LPI, BSD certification will gain a new global reach. 

It will also benefit as it’s relaunched in 2018 to fit into a broader program of 
free and open source professional credentials. You can help Linux 

Professional 

by participating in retooling the certification at lpi.org/bsd. V— / institute 


COMING IN 2018. 
WATCH FOR UPDATES 
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Every two months I sit down at my computer and dig through 
thousands of commit messages, looking for the most exciting 
and interesting changes, and then spend the next few hours 
curating them into a column called svn Update. As my daughters 
got older and my responsibilities at work increased, finding 
those few hours started to become increasingly difficult. 

I am finally ready to admit to myself that the time has come to 
step back from producing these ramblings. I hope you have 
enjoyed these columns as much as I have enjoyed preparing 
them. I thank you all from the bottom of my heart. Good night, 
and good luck. 

Expose the kernel's build-ID through sysctl— 

http s://sv nweb. freeb sd.org/chanqeset/b ase/3 48611. 

fter our migration (of certain architectures) to lid, the kernel is built with a unique 



/xbuild-ID. Make it available via a sysctl and uname(l) to allow the user to identify 
their running kernel. 

Modify mountd so that it incrementally updates the kernel exports 
upon a reload — htt ps://sv n web.freeb sd.org/chanqeset/base/348590. 

ithout this patch, mountd would delete/load all exports from the exports file(s) 



V V when it receives a SIGHUP. This works fine for small exports file(s) but can take 
several seconds to do when there are large numbers (10,000+) of exported filesys¬ 
tems. Most of this time is spent doing the system calls that delete/export each of 
these filesystems. When the "-S" option has been specified (the default these days), 
the nfsd threads are suspended for several seconds while the reload is done. 

This patch changes mountd so that it only does system calls for filesystems where 
the exports have been changed/added/deleted as compared to the exports done for 
the previous load/reload of the exports file(s). Basically, when SIGHUP is posted to 
mountd, it saves the exportlist structures from the previous load and creates a new set 
of structures from the current exports file(s). Then it compares the current with the 
previous, and only does system calls for cases that have been changed/added/deleted. 
The nfsd threads do not need to be suspended until the comparison step is being 
done. This results in a suspension period of milliseconds for a server with 10.000+ 
exported filesystems. 

Add Chacha20 mode to Encrypted Kernel Crash Dumps— 

http s://sv nw eb.freeb sd.org/chanqeset/b ase/3 48197. 



hacha20 does not require messages to be multiples of block size, so it is valid to 
use the cipher on non-block-sized messages without the explicit padding AES- 
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CBC would require. Therefore, allow use with simultaneous dump compression. 
(Continue to disallow use of AES-CBC EKCD with compression.) 

dumpon(8) gains a -C cipher flag to select between chacha and aes-cbc. It 
defaults to chacha if no -C option is provided. The man page documents this 
behavior. 

Add GRE-in-UDP encapsulation support as defined in 
RFC8086 — https://svn web.freeb sd.org/chan gese t/base/346630. 

his GRE-in-UDP encapsulation allows the UDP-source port field to be used as 



I an entropy field for load-balancing of GRE traffic in transit networks. Also, 
most of multiqueue network cards are able distribute incoming UDP datagrams 
to different NIC queues, while very few are able do this for GRE packets. 

Add IPv6 transport for bsnmp— 

https://svnweb.freebsd.org/chanqeset/base/345797. 

his patch adds a new table begemotSnmpdTransInetTable that uses the 



I InetAddressType textual convention and can be used to create listening ports 
for IPv4, IPv6, zoned IPv6 and based on DNS names. It also supports future 
extension beyond UDP by adding a protocol identifier to the table index. 

Allow explicitly assigned IPv6 loopback address to be used 
in jails — https://svnweb.freebsd.0rg/chanqeset/base/316328. 

I f a jail has an explicitly assigned IPv6 loopback address, then allow it to be 
used instead of remapping requests for the loopback adddress to the first IPv6 
address assigned to the jail. This fixes issues where applications attempt to 
detect their bound port where they requested a loopback address, which was 
available, but instead, the kernel remapped it to the jails first address. 

Drop i486 from the default i386 GENERIC kernel config¬ 
uration — https://svnweb.freebsd.0rg/chan qese t/base/314669. 

8 0486 production was stopped by Intel on September 2007. Dropping the 
486 configuration option from the GENERIC kernel improves 
performance slightly. 

Removing I486_CPU is consistent at this time: we don't support any proces¬ 
sor without a FPU, and the PC-98 arch, which frequently involved i486 CPUs, is 
also gone, so we don't test such platforms anymore. 
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BY DRU LAVIGNE & ANNE DICKISON 

The Following BSD Events will take place 
during the third quarter of 2019 


USENIX 
ATC '19 


USENIX ATC • July 10-12 • Renton, WA 

ht tps://www.usenix.org/co n ference/atc19 USENIX ATC brings 
together leading systems researchers for the presentation of cutting-edge 
systems research and the opportunity to gain insight into a wealth of must- 
know topics, including virtualization; system and network management and 


troubleshooting; cloud and edge computing; security, privacy, and trust; mobile and wireless; and more. 


O'REILLY 

os on 

OPEN SOURCE CONVENTION 


OSCON • July 15-18 • Portland, OR 

h ttps://conferences.or e illy.com/oscon/oscon-or The open-source software 
conference. The FreeBSD Foundation will have a table in the expo hall to pro¬ 
mote FreeBSD. 


ST 



SCINOG 


SANOG34 • July 31-August 7 • Kolkata, India 

http://www.sano g .org/sanog34/ Join members of the Foundation team at the 32nd 
Conference of South Asian Network Operators Group (SANOG). The event will provide a valuable opportunity 
to contribute to discussions about Internet operations, technologies, and development. 





con 

VERISIGN 


vBSDcon • September 5-7 • Reston, VA 

http s://vbsdcon.com vBSDcon is a biennial technical conference 
bringing together members of the BSD community for a series of round¬ 
table discussions, educational sessions, best practice conversations, and 
exclusive networking opportunities. 



EuroBSDCon • September 19-22 • Lillehammer, 

Norway https://201 9.euro bsdcon.org/ 

The 18th European BSD Conference will take place in Lillehammer, Norway, on 
September 21-22. Workshops and tutorials will take place on September 19-20. 

^- 



36 


FreeBSD Journal 



































































